科技新知
Swarm mode 上線 5 - load balancer | 還有那些事該考量？
前面介紹了 ingress network ，亦介紹了 proxy gateway 。能做到的基本都做到了，再來就是考量安全性的問題。因為加了 proxy gateway ，前述的例子是所有 service ，都放在同一個 yaml 檔中。好處是，所有相關的東西存放在同一個檔中， gateway ，背後的 service 都一眼看到。但壞處就是有其中一個 service 更新，都要改那個 yaml 檔。更大的問題是， stack deploy 的指令，不單只更新其中一個 service ，就連其他 service 都會自動取得最新 image 而 redeploy 。
對於一個緊密的系統來講，同步更新可能不是大問題。但對於一些預定排程發佈的系統可不能這樣因為副作用而更新了。如果你也有這樣的分開管理需求，可以參考下面做法，把 gateway service 及 upstream service 放在不同的檔案中，然後經過 external network把所有 service 串連起來。
# nginx-stack.yaml, docker stack deploy -c nginx-stack.yaml nginx
services:
http-gateway:
image: http-gateway
ports:
- 8080:8080
deploy:
replicas: 1
update_config:
delay: 10s
restart_policy:
condition: on-failure
# manager-stack.yaml
services:
managerhttp:
image: bretfisher/httpenv
networks:
- nginx_default
- default
deploy:
replicas: 3
update_config:
delay: 10s
restart_policy:
condition: on-failure
placement:
constraints:
- node.labels.zone==manager
networks:
nginx_default:
external: true
# dmz-stack.yaml
services:
dmzhttp:
image: bretfisher/httpenv
networks:
- nginx_default
- default
deploy:
replicas: 2
update_config:
delay: 10s
restart_policy:
condition: on-failure
placement:
constraints:
- node.labels.zone==dmz
networks:
nginx_default:
external: true
這樣，不同 service 的維護人員，就可以獨自控制自己的檔案。在第一次發佈時，確認 nginx-stack.yaml 先行發佈就可以了。對應的發佈指令是docker stack deploy -c nginx-stack.yaml nginx，它會自動産生一個 nginx_default （即 stack名字_default ）的網絡。之後其他service，就可以經networks的設定找到它了。
services:
YOUR_SERVICE:
networks:
- nginx_default
- default
networks:
nginx_default:
external: true
上述即使分離檔案，在安全性考量時還是有一個問題，就是 ingress network 的問題。試想一下，dmzhttp （Demilitarized Zone）原本被設定的原因，就是想限制某些訪問只能一些可以公開的服務。但因為經過 ingress network 之後，它們會在所有機器上開放這些 port。那就是，以下面的例子來講，若 dmzhttp 是公開的服務， intrahttp 是內部服務，即使用 intrahttp 使用不同的port 8889。但一經 swarm mode 預設的 ingress network ，在node.labels.zone==dmz的那些節點，還是可以訪問到 intrahttp 。
services:
dmzhttp:
image: bretfisher/httpenv
ports:
- 8888:8888
deploy:
replicas: 2
update_config:
delay: 10s
restart_policy:
condition: on-failure
placement:
constraints:
- node.labels.zone==dmz
intrahttp:
image: bretfisher/httpenv
ports:
- 8889:8888
deploy:
replicas: 3
update_config:
delay: 10s
restart_policy:
condition: on-failure
placement:
constraints:
- node.labels.zone==intra
我們前述介紹的 proxy gateway ，其實已經有一定程度可以解決這個問題。因為 proxy gateway 是根據 http 協定中的 host header 去做分流。在邊界網絡進來的「合法」訪問，道理上會好好地經引導到我們的 dmzhttp 。不過網路的邪惡可容小看， proxy gateway 也會有被騙的一日。有特定能力的攻擊者，只需找到目標域名，還是可以接觸到 intrahttp 。
若要做進一步隔離，在這種情況下，我們可以在 dmz , intra 機器中各設定一套 swarm ，完全獨立，這是最安全的做法。但這樣做的管理成本就會變高，因為兩個網段都會有自己的 manager 節點，而且在 dmz 網段的 manager 節點也有被攻擊的可能。
若我們回到單一 swarm 的方向，可以修改各個 service 中的 port 和 deploy 。利用 post mode 中的「host」，配合 deploy mode 中的「global」，完全跳開 ingress network。
services:
dmzhttp:
image: nginx
ports:
- target: 80
published: 8888
mode: host
deploy:
mode: global
update_config:
delay: 1s
restart_policy:
condition: any
placement:
constraints:
- node.labels.zone==dmz
intrahttp:
image: bretfisher/httpenv
ports:
- target: 8888
published: 8888
mode: host
deploy:
mode: global
update_config:
delay: 10s
restart_policy:
condition: on-failure
placement:
constraints:
- node.labels.zone==intra
上面的例子中， dmzhttp 會在所有 dmz 的機器中，每個節點只運行一份服務，而且直接使用該機的 8888 port ，外面不會再有 ingress network 的 存在。同樣地，intrahttp 會在 intra 的所有節點，運行一份服務，佔用它們的8888 。這兩個服務，即使使用一個 port ，swarm 也不會說有任何問題。因為它們不會經 ingress network 搶佔其他人的 8888。
可能會有讀者問，如果 host mode 這麼安全，為什麼預設會是 ingress network，那我們就要先了理清 ingress network 與 host mode 有有什麼分別？假設我們只運行一個service，它佔用8888。
| 功能 | ingress mode | host mode |
|---|---|---|
| replicas 數 | 同一個 service replicas 為任意數量，什至比節點的數目多 | 因為有 port 限制，每個節點最多只能運行一份 |
| Virtual IP | Virtual IP 任意在節點中跳轉也可以，因為 ingress 會自動找到對應的 service 所在的節點 | Virtual IP必需要與 service 所在節點綁定，其他節點訪問不到 |
| load balance | 有 | 沒有 |
host mode 就像我們傳統在各自的節點上自行佈署自己的程序，各個節點只有一份。所以不會有自動 load balance 的效果，如果客戶端訪問固定的IP，就會得到是固定的接器接受請求。我們有需要，就要在前面加一個 Proxy Gateway (或 HA proxy )。 Virtual IP 也一樣， host mode 下需要好好地自動跟著 service 的生命期，不過幸運的是， Docker 預設己經有自動重啟 service 功能，即前文中的 restart_policy ，它在 host mode 下也適用。如果大家有配合 deploy 中的 global mode ， Virtual IP 的並沒有實際變動。但如果沒有 global mode ，就要再想想辦法了。
最後考慮 load balance 的問題，如果進入點的 service 的真的不太消耗資源，沒有 load balance 也是可以的 ，但若超負荷，就必需要自建 proxy gateway 。經過進入點後，若我有背後的 service 就沒有所謂的 ingress 和 host mode 選擇。
